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We describe a new, dynamic, floating-label approach to language-based information flow control. A labeled IO monad, 
jy^ , LIO, keeps track of a current label and permits restricted access to 10 functionality. The current label floats to exceed 

O ■ the labels of all data observed and restricts what can be modified. Unlike other language-based work, LIO also 

bounds the current label with a current clearance that provides a form of discretionary access control. Computations 
may encapsulate and pass around the results of computations with different labels. In addition, the LIO monad 
offers a simple form of labeled mutable references and exception handling. We give precise semantics and prove 
| confidentiality and integrity properties of a call-by-name A-calculus and provide an implementation in Haskell. 
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Abstract 



1 Introduction 



Complex software systems are often composed of modules with different provenance, trustworthiness, and 
functional requirements. A central security design principle is the principle of least privilege, which says 
that each component should be given only the privileges it needs for its intended purpose. In particular, 
" it is important to differentially regulate access to sensitive data in each section of code. This minimizes 

the trusted computing base for each overall function of the system and limits the downside risk if any 
component is either maliciously designed or compromised. 

Information flow control (IFC) tracks the flow of sensitive data through a system and prohibits code 
from operating on data in violation of a security policy. Significant research, development, and experi- 
mental effort has been devoted to static information flow mechanisms. Static analysis has a number of 
benefits, including reduced run-time overhead, fewer run-time failures, and robustness against implicit 



flows (Denning & Denning, 1977 1. However, static analysis does not work well in environments where 
new classes of users and new kinds of data are encountered at run-time. In order to address the needs of 
such systems, we describe a new, dynamic, floating-label approach to language-based information flow 
control and present an implementation in Haskell. 

Our approach uses a Labeled type constructor to protect values by associating them with labels. The 
labels themselves are typed values manipulated at run-time, and can thus be created dynamically based on 
other data such as a username. Conceptually, at each point in the computation, the evaluation context has 
a current label. We use a labeled IO monad, LID, to keep track of the current label and permit restricted 
access to IO functionality (such as a labeled file system), while ensuring that the current label accurately 
represents an upper bound on the labels of all data observed or modified. Unlike other language-based 
work, LIO also bounds the current label with a current clearance. The clearance of a region of code may 
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be set in advance to impose an upper bound on the floating current label within that region. This restricts 
data access, limits the amount of code that could manipulate sensitive data, and reduces opportunities to 
exploit covert channels. Additionally, we introduce an operator, toLabeled, that allows the result of a 
computation that would have raised the current label to be encapsulated within the Labeled type. Finally, 
we present combinators for working with labeled references, and exceptions. Thanks to the flexibility 
of dynamic checking, LIO implements an IFC mechanism that is more permissive than previous static 
approaches ( |Pottier & Simonet, 2002[|Li & Zdancewic, 2010 ; Russo et ai, 2008| but provides similar se- 
curity guarantees ( |Sabelfeld & Russo, 2009) 1. Though purely language-based, LIO explores a new design 
point centered on floating labels that draw on past OS work (Zeldov ich et ai, 2006] > . 

The main features of our system can be understood using the example of an online conference review 
system, called AChair. In this system, which we describe more fully later in the paper, authenticated users 
can read any paper and can normally read any review. This reflects the normal practice in conference 
reviewing, for example, where every member of the program committee can see submissions and their 
reviews, and participate in related discussion. Users can be added dynamically and assigned to review 
specific papers. As an illustration of the power of the labeling system, integrity labels are used to make 
sure that only assigned reviewers can write reviews for any given paper. Conversely, confidentiality labels 
are used to manage conflicts of interest. Users with a conflict of interest on a specific paper lack the 
privileges, represented by confidentiality labels, to read a review. As conflicts of interest are identified, 
confidentiality labels on the papers may change dynamically and become more restrictive. 

This paper extends an earlier conference version ( |Stefan et ai, 201 ib] > by including formal proofs and 
extending the calculus and library implementation with exception handling. The main contributions of 
this work are: 

► We propose a new design point for IFC systems in which most values in lexical scope are protected by a 
single, mutable, current label, yet one can also encapsulate and pass around the results of computations 
with different labels. Label encapsulation is explicitly reflected by types in a way that prevents implicit 
flows. 

► We prove information flow and integrity properties of our design and describe LIO, an implementation 
of the new model in Haskell. LIO, which can be implemented entirely as a library (relying solely on 
type safety), demonstrates both the applicability and simplicity of the approach. 

► Unlike other language-based work, our model provides a notion of clearance that imposes an upper 
bound on the program label, thus providing a form of discretionary access control on portions of the 
code, i.e., restricting access to data it "needs to know". 

► We present a novel dynamic, yet safe, handling of exceptions. Exceptions are a key component to make 
LIO a more practical IFC system. 

This paper is organized as follows. Section [2] provides background on information flow control and 
our Haskell LIO library. Section [3] presents a motivating scenario where to apply LIO. Formalization of 
the library is given in Section |4] and the security guarantees are detailed in Section [5] Related work is 
described in Section|6] We conclude in Section|7] 



2 Security Library 

In this section, we give an overview of information flow control, the approach used by LIO to dynamically 
enforce IFC, and the core application programming interface (API) provided by our library. 
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Labels and IFC The goal of information flow control is to track the propagation of information and 
control it according to a security policy. A well-known policy addressed in almost every IFC system is 
non-interference: publicly-readable program results must not depend on secret inputs. A non-interfering 



program is guaranteed to preserve confidentiality of sensitive data (Goguen & Meseguer, 1982 1; dually, 



this policy can be used to preserve integrity of trustworthy data ( Biba, \911\ . 

To enforce information flow restrictions, most systems associate labels with every piece of data. A 



label represents the level of confidentiality and integrity on data. Labels form a lattice (Denning, 19761 
with partial order C (pronounced "can flow to"); IZ is used to govern the allowed flows between differently 
labeled entities. For instance, if L\ C L 2 holds, it indicates that data with label L\ can flow into entities 
labeled L 2 - 

LIO is polymorphic in the label type, allowing different types of labels to be used. Custom label formats 
can be created by providing a definition for a bounded lattice. Specifically, a label format must have a 
well-defined partial order (□), a binary operation computing the join of two labels (U), a binary operation 
computing the meet of two labels (11), and minimum (_L) and maximum (T) elements. For any two labels 
L\ and Li, the join has the property that L, □ (L\ YALq),i = 1,2 and L\ UL2 is the least of such elements 
in the lattice; the meet has the property that (L\ IIL2) ^= L{,i =1,2 and L\ HLi is the greatest of such 
elements in the lattice. In our Haskell library, label types are instances of the Label type class: 

class (Eq 1) => Label 1 where 

leq : : 1 — > 1 — > Bool — Can flow to relation (C) 
lub : : 1 — > 1 — > 1 — Join operation (U) 
gib : : 1 — > 1 — > 1 — Meet operation (11) 
lbot : : 1 — Minimum element (_L) 

ltop : : 1 — Maximum element (T) 

Henceforth we assume that the bounded lattice property holds for the labels used in our examples. 
Section [3] details disjunction category (DC) labels, a concrete label format used int A Chair that satisfies 
this property. 

Privileges and Decentralized IFC An extension of IFC, the decentralized label model (DLM) of Myers 



and Liskov (Myers & Liskov, 1997 1 allows for more general applications, including systems consisting of 
mutually distrustful parties. In a decentralized system, a computation is executed with a set of privileges 
p, which, when exercised, allow the computation to "bypass" certain label restrictions. In such systems, 
rather than using the standard C partial order relation, a more permissive pre-order C p , is used in the label 
comparisons. Consider, for example, a simple four-point lattice 1 C L; C Lab, for i =A,B. Here, La, Lb, 
and Lab respectively correspond to data private to user A, user B, and both A and B. In DLM, privileges 
and labels are associated such that, e.g., privilege a corresponding to La allows user A to "ignore the A" in 
labels. Thus, Lab =« Lb, even though Lab % Lb- This property is very useful as it allows A to downgrade 
the data from label level Lab to Lb- Informally, when downgrading, the code exercising the privilege states 
that it no longer considers the data to be confidential (in this case, A exercising a to downgrade data from 
Lab to Lb)- Note that downgrading does not make the data publicly readable, all parties corresponding to 
the label must first perform the downgrade. 

As in the case of labels, our library is polymorphic in the privilege types. Any code can exercise 
privileges (that are in lexical scope) to enforce IFC using the more permissive C p relation. However, 
our formalism is limited to non-privileged primitives and we thus do not discuss privileges further. We 
refer the interested reader to the library documentation for details on privileges. 
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LIO computations LIO is a language-based floating-label system, inspired by IFC operating systems, 
including HiStar ( |Zeldovich et al, 2006) 1 and Asbestos (Efstathopoulos et al, 2005 1. In a floating-label 



system, the label of a computation can rise to accommodate reading sensitive data, similar to the program 



counter of more traditional language-based systems (Sabelfeld & Myers, 2003 1. Specifically, in LIO, a 
computation C with label Lq wishing to observe an object (e.g., a review) labeled Lr can do so by first 
raising its label to the join of the labels: LcULr. Consider, for example, a simple AChair review system 
computation that retrieves the content of a review, and writes it to an output channel. 

readReview R = do — Initial computation label: Lq 

rv retrieveReview R — Computation label when retrieving : L^-ULr 
printLabeledCh rv — Computation label when printing : LcULr 

Here, we assume that the computation is executing on behalf of a user, Clarice, with initial label Lq and 
that review R has label Lr. The computation label is shown in the comments as the different actions are 
executed. Internally, the retrieveReview function is used to retrieve the review contents rv; the function 
raises the computation label to Lq U Lr to reflect the observation of sensitive review information. This 
directly highlights the notion of a "floating-label": a computation's label effectively "floats above" the 
labels of all objects it observes. 

The floating label is used to restrict writes: a computation cannot write to an entity whose label is below 
the computation label. In the example, the action printLabeledCh rv, which performs a write, does not 
change the computation label. However, printLabeledCh returns an action that writes the review content 
rv to standard output channel, labeled Lq, only if LcULr QLq. In AChair, the standard output channel 
label, Lo, is dynamically set according to the user executing the computation; Lo is set so as to allow for 
printing out all but the conflicting reviews. Thus, if user Clarice has a conflict of interest with review R, 
Lo is set such that Lr %Lo. 

Unlike existing language-based IFC systems, LIO also associates a clearance with each computation. 
This clearance sets an upper bound on the current floating label within some region of code. For example, 
the notion of clearance can be used to prevent Clarice from retrieving (and not just printing) the contents 
of a conflicting review R by setting the computation's clearance to Cc such that Lr % Cc- In general, 
before raising the computation label, LIO combinators first check that the new label will not exceed the 
computation clearance. Hence, when the action retrieveReview R attempts to raise the current label to 
LcULr, the computation will fail since LqULr % Cc- 

More interestingly, clearance can be used to prevent malicious code from exploiting covert channels. 
For example, without clearance, the following function can be used by a user, such as Clarice, to leak 
information on reviews which she is in conflict with: 

leakingRetriveReview r = do — Initial label: Lq 

rv <— retrieveReview r — Retrieving : Lq\ALr (if LqYALr^Cc) 

covertChannel rv — Leak review into covert channel 

The function covertChannel leaks (part of) the sensitive review content into a covert channel, such as 
the termination channel. In the latter case, the function leaks information by deciding whether or not to 
diverge based on sensitive data. A simple example that leaks a bit is given below. 

covertChannel rv = 

if rv== " Paper ... " — If sensitive review matches "Paper..." 

then forever (return rv) — then loop forever 

else return rv — otherwise return 
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Using clearance, we prevent such leaks by setting the clearance and review labels such that retrieveReview 
fails when it attempts to raise the computation label to retrieve conflicting reviews (the additional check 
L c U L R C C c will not hold). 

2.1 Library Interface 

LIO is a termination-insensitive and flow-sensitive ( |Askarov et al., 20081 |Hunt & Sands, 2006| IFC li- 
brary that dynamically enforces information flow restrictions. At a high level, LIO defines a monad called 
LIO, intended to be used in place of 10. The library furthermore contains a collection of LIO actions, many 
of them similar to 10 actions from standard Haskell libraries, except that they contain label checks that 
enforce IFC. 

To implement the notion of floating label that is bounded by a clearance, our library defines LIO as a 
state monad, parametric in the label type, and using 10 as the underlying base monad. The state consists of 
a current label L cur , i.e., the computation's floating label, and a current clearance C cur , which is an upper 
bound on -Lcur? i.e., Lcur != Ccur always holds. The (slightly simplified) LIO monad is defined as: 

newtype LIO 1 a = LI0TCB (StateT (1, 1) 10 a) 

where the state corresponds to the current label and clearance. To allow for the execution of LIO actions, 
our library provides the function evalLIO that takes an LIO action and returns an 10 action which, when 
executed, will return the result of the IFC-respecting computation. It is important to note that untrusted 
LIO code cannot execute 10 computations by binding 10 actions with LIO ones (to bypass IFC restrictions), 
because LI0TCB is a private symbol. Effectively this limits evalLIO to trusted code. Additionally, using 
evalLIO, trusted programmers can easily, though cautiously, enforce IFC in parts of an otherwise IFC- 
unaware program. 

The current label provides a means for associating a label with every piece of data. Hence, rather than 
individually labeling definitions and bindings, all symbols in scope are protected by L cur . Moreover, the 
only way to read or modify differently labeled data is to execute (trusted) actions that internally access 
restricted symbols and appropriately validate and adjust the current label (or clearance). 

In many practical situations, it is essential to be able to manipulate differently-labeled data without 
monotonically increasing the current label. For this purpose, the library additionally provides a Labeled 
type for labeling values with labels other than L C ur- A Labeled, polymorphic in the label type, protects 
an immutable value with a specified label irrespective of the current label. This is particularly useful 
as it allows a computation to delay raising its current label until necessary. For example, an alternative 
retrieveReview implementation can retrieve the review content, convert it to HTML, encapsulate the 
markup into a Labeled value, and return the Labeled value while leaving the current label unchanged. 
This approach delays the "creeping" of current label until the review content, as encapsulated by Labeled, 
is actually needed. 

We note that LIO can be used to protect pure values in a similar fashion to Labeled. However, the 
protection provided by Labeled allows for serializing labeled values and straight forward inspection 
by trusted code (which may ignore the protecting label). Unlike LIO, Labeled is not a monacal. The 
monad instance would allow a computation to use bind and return to arbitrarily manipulate labeled 
values without any notion of the current label or clearance, and thus (possibly) violate the restriction 

1 In fact, Labeled cannot be a functor; this would violate non-interference when considering integrity into the 
security labels. 
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that LIO computations should not handle values below their current label or above their current clearance. 
Moreover, the Monad instance would require a definition for a default label necessary when lifting a value 
with return. Instead, our library provides several functions that allow for the creation and usage of labeled 
values within LIO. Specifically, we provide (among other) the following functions: 

► label :: Label 1 =>1 ->a ->-LID 1 (Labeled 1 a) 

Given a label I such that L cur C / C C cur and a value v, the action label / v returns a labeled value that 
protects v with /. 

► unlabel : : Label 1 =>Labeled 1 a -^LIO 1 a 

Assuming that lv is associated to label /, the action unlabel lv raises the current label to L cur U / if 
L cur U / C C cur and returns the unlabeled value. Note that the new current label is at least as high as lv's 
label, preserving the confidentiality of the value. 

► toLabeled : : Label 1 =>1 ->LI0 1 a ->LI0 1 (Labeled 1 a) 

Given a label / such that L cur C / C C cur and an LIO action m, toLabeled / m executes m without raising 
the current label. However, instead of returning the result directly, the function returns the result of m 
encapsulated in a Labeled. The label of the labeled value is /; to preserve confidentiality (see SectionH] 
for further details), action m must not read any values with a label above /. In monadic terms, toLabeled 
is an environment-oriented action that provides a different context for a temporary bind thread. 

► labelOf : : Label 1 =>Labeled 1 a ->1 

If lv is a labeled value with label / and value v, labelOf lv returns /. 
Our library additionally provides labeled alternatives to mutable references, i.e., IORef s. Specifically, we 
provide labeled references LIORef 1 a that are created with newLIORef , read with readLIDRef , and 
written to with writeLIORef . When creating or writing to a reference with label Lr, it must be the case 
that L cm - QLrQ C cur ; when reading L cur is raised to L cur ULr, clearance permitting. 

In the conference version of this work ( St efan et ai, 201 lb} , the execution of programs stop when the 
IFC constraints imposed by the C-relationship are not fulfilled. Similar to other dynamic IFC approaches 
(e.g., flAskarov & Sabelfeld, 20091 |Russo & Sabelfeld, 20091 |Austin & Flanagan, 2010| », this design de- 



cision restricts the possibilities for programs to recover from failures. Later in this section, we show how 
to extend LIO with exception handling so that programs can recover from failures or insecure actions 
without compromising confidentiality or integrity of data. 

The formal semantics for the functions described above are given in Section O in this section, we 
illustrate their functionality and use through examples. Specifically, consider the previous example of 
readReview. The internal function retrieveReview takes a review identifier R and returns the review con- 
tents. Internally, retrieveReview must have access to a list of reviews, which are individually protected 
by different labels. In this model, adding a new review to the system can be implemented as: 

addReview R Lr rv = do 

r <— label Lr rv — Checks L cur jZ Lr IZ C CU r 

addToReviewList R r — Appends labeled review to internal list 

where the addToReviewList simply adds the Labeled review to the internal list. The implementation of 
retrieveReview is similar: 

retrieveReview R = do — Initial label, L cur = Lq 

r getFromReviewList R — Retrieving a labeled result, L cur = Lc 

rv unlabel r — Unlabel result, raises label to L cui =L^ULr 

return rv — Returning unlabeled content, L ait =Lc\ALR 
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where the getFromReviewList retrieves the Labeled review from the internal list and unlabel removes 
the protecting label, raising the current label to reflect the observation. 

We previously alluded to an alternative implementation of retrieveReview that returns the labeled, 
review content in HTML form while keeping the current label the same. This implementation can be 
directly leverage the above retrieveReview: 

retrieveReviewHtml R = do — Outer: Initial label, L cul - = Lq 

r 4— toLabeled (LqULr) $ do — Inner: Initial label, L cul - = Lq 

rv <— retrieveReview R — Inner: Retrieve review, L cur = Lq LI Lr 
return (toHtml rv) — Inner: Return review, L cm = LqYALr 

return r — Outer: Return labeled review, L cur = Lq 

Note that although the current label within the inner computation is raised, the outer computation's label 
does not change — instead the marked-up review content is protected by the label Lq ULr. Hence, only 
when the review content is actually needed, unlabel can be used to retrieve the content and raise the 
computation's label accordingly: 

readReviewHtml R = do — Initial label L cm = Lq 

r retrieveReviewHtml R — Retrieve labeled review, L CU i = Lc 

— Perform other computations , such that L cur = L' c 

rv <— unlabel r — Unlabel labeled review, L cui = L' c ULr 

printLabeledCh rv — Print review content, L cm = L' c ULR 



2.1.1 Exception handling 

Exception handling is common in real-world applications, and, as already noted, LIO provides support 
for such constructs. Throwing an exception depends on the information present in the lexical scope. 
Consequently, LIO labels an exception with the current label (L cm ) at the point where the exception is 
thrown. Specifically, the primitive 

throwLIO : : (Exception e) =>• e — > LIO 1 a 

takes an arbitrary exception and wraps it into a labeled exception type: 

data LabeledException 1 e = ... 

which itself is an instance of Exception. The label of the exception is set to the current label L cur . 
Conversely, the primitive: 

catch : : (Exception e) => LIO 1 a — > (e — >• LIO 1 a) — > LIO 1 a 

can be used to execute an LIO action, using an exception handler to address the case when the computation 
raises an exception. Suppose the current label and clearance are L cur and C cur , respectively. Given a 
computation m, and an exception handler he, catch m he executes m and then: 

1. if no exception is thrown, the result produced by catch is simply the result of m, leaving the current 
label and clearance unchanged (as of the execution of m). 

2. if an exception with label / C C cur is thrown when executing m, the current label raised to L cur U / and 
the exception handler is invoked (if the exception type matches). Raising the current label to L cur U I 
before executing the exception handler indicates that the handler must not produce side-effects at 
security levels lower than the one indicated by the label of the exception. 
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3. if an exception with label / % C cur is thrown, the exception label is raised to L cm U I and re-thrown 
(propagated to an outer catch). 

It is worth remarking that primitive catch is the only means for inspecting information related to an 
exception (e.g., kind of exception, security label, etc.). 

Safe propagation of exceptions In LIO, the standard propagation of exceptions up the call stack until 
reaching the nearest enclosing catch can be used to leak information. Consider the following function: 

condThrow : : LIORef 1 Bool -* LIO 1 () 
condThrow secRef = do 

sec <— readLIORef secRef 

if sec then throwLIO . . . else return () 

Assuming that condThrow is invoked with the current label L cur and secRef has label Lr, throwLIO raises 
an exception labeled L cur U Lr if the secret value stored in the reference is True. The exception label 
indicates that the exception was raised after performing a secret read. 

Although condThrow cannot directly be used to leak information, it is important to highlight that the 
function throws an exception if the secret is True, and returns () otherwise. Hence, in the presence of 
toLabeled, which restores the current label, it is important to reason about the propagation of excep- 
tions. More specifically, if exceptions propagate until reaching the nearest enclosing catch, the following 
function can be used to leak information: 

leaklntoPub : : LIORef 1 Bool ->• LIORef 1 Bool LIO 1 
leaklntoPub secRef pubRef = catch ( 
do writeLIORef pubRef True — Write to ■public reference #1 

<— toLabeled T $ condThrow secRef — Throw exception if secret is True 
writeLIORef pubRef False — Write to public reference #2 

) (A_ — ¥ return ()) — Handle exception 

Suppose that the function is invoked with a current label L cm = -L and current clearance C cm = T, secRef 
is labeled T and pubRef is labeled JL. Initially, the computation can directly read and write to pubRef, but 
only read from secRef. 

Note that catch is only used to force normal termination, i.e., execution of function leaklntoPub always 
return () . More importantly, note that public side-effects are performed before (writeLIORef pubRef True) 
and after (writeLIORef pubRef False) executing a computation on secret data (condThrow secRef). 
(This is possible because the computation condThrow secRef is enclosed in a toLabeled block, and thus 
the current label remains unchanged.) Moreover, if the value of the secret reference secRef is True, then 
an exception is raised in condThrow and further propagated to the enclosing catch without executing 
the second write to the public reference (writeLIORef pubRef False). Hence, if an exception is raised 
in condThrow the content of pubRef remains True. In contrast, if no exception is thrown, the content of 
pubRef is set to False: clearly, a direct leak of the value stored in secRef. 

It is important to finally note that although catch will raise the current label when an exception raised 
in the secret computation, leaklntoPub can also be enclosed by toLabeled: 

leakSecretRef : : LIORef 1 Bool -> LIO 1 Bool 
leakSecretRef secRef = do 

pubRef <— newLIORef J_ True — Create public reference 

toLabeled T $ leaklntoPub secRef pubRef — Perform attack 

readLIORef pubRef — Read "secRef" value 
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This function returns the content of the secret reference secRef without raising the current label. 

Due to the feasibility of such attacks, LIO propagates exceptions up to the nearest catch or toLabeled. 
Intuitively, the correct semantics of toLabeled are as before with the added requirement that all exceptions 
be caught: regardless how the computation enclosed by toLabeled terminates, a Labeled value must 
always be returned. Conceptually this is equivalent to labeling a lifted value, i.e., a value that may be a 
"normal" value or an exception. Of course, if the result of unlabel is an exception, the exception will 
propagate to the nearest catch or toLabeled. 

Considering this modification to the semantics of toLabeled, observe that the side-effects in leaklntoPub 
produced after the toLabeled block will always be executed (even if an exception is raised inside condThrow). 
More generally, we close up leaks through exception propagation by simply assuring that the execution of 
(possibly public) actions following a toLabeled block does not depend on the abnormal termination of a 
computation inside toLabeled. 

Recovery of unsafe actions Unlike other dynamic IFC approaches, such as ( Askarov & Sa belfeld, 2009| 
ISabelfeld & Russo, 2009"l|Austin & Flanagan, 200"9{| Austin & Flanagan, 20T0l|Devriese & Piessens, 201 



LIO allows untrusted programs to safely recover from failures due to IFC violation attempts (e.g., trying to 
create labeled values below the current label, or read from a reference labeled above the current clearance, 
etc.) Having a safe handling of exceptions in place, LIO raises a labeled exception when a security 
constraint is not fulfilled. This allows untrusted code to catch exceptions and handle monitor failures 
gracefully. Consider, for instance, the following function that unlabels a Labeled value and returns a 
Maybe value to indicate the success of such operation: 

safeUnlabel : : Labeled a —t LIO 1 (Maybe a) 

safeUnlabel lv = catch ( do v f- unlabel lv — Fails if labelOf lv % C CU r 

return (Just v) 
) (A_ — > return Nothing) 

If the label of lv is above the current clearance, the LIO primitive unlabel throws an exception. In this 
example, however, this exception is caught (since the label of the exception will be L cur and the exception 
handler will simply return Nothing). If the label of lv is below the clearance, the current label is raised 
and the unlabeled result is simply returned. 



3 A Chair 

To demonstrate the flexibility of our dynamic information flow library, we present A Chair, a simple API 
(built on the examples of Section |2]i for implementing secure conference reviewing systems. In general, 
a conference reviewing system should support various features (and security policies) that a program 
committee can use in the review process. Minimally, it should support: 

► Paper submission: ability to add new papers to the system. 

► User creation: ability to dynamically add new reviewers. 

► User login: a means for authenticating users. 

► Review delegation: ability to assign reviewers to papers. 

► Paper reading: means for reading papers. 

► Review writing: means for writing reviews. 

► Review reading: means for reading reviews. 

► Conflict establishment: ability to restrict specific users from reading conflicting reviews. 
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Even for such a minimal system, a number of security concerns must be addressed. First, only users 
assigned to a paper may write the corresponding reviews. Second, information from the review of one 
paper should not leak into a different paper's review. And, third, users should not receive any information 
on the reviews of the papers with which they are in conflict. 

AChair's API provides the aforementioned security policies by applying information flow control. 
Following the examples of Section [2] we take the approach of enforcing IFC when writing to output 
channels, and thus the security for the above policies correspond to that of non-interference, i.e., secret 
data is not leaked into less secret channels/reviews. The alternative, clearance-restricting approach of 
Section [2] can be used to enforce the security policies by confinement rather than non-interference (see 
Section|5]i. Before delving into the details of the AChair, we first introduce the specific label format used 
in the implementation. 

3.1 DC Labels 

AChair is implemented using Disjunction-Category (DC) labels ( |Stefan et al, 201 la) . DC labels can be 
used to express a conjunction of restrictions on information flow that represents the interests of multiple 
stake-holders. As a result, DC labels are especially suitable for systems in which participating parties do 
not fully trust each other, e.g., a conference review system. 

Policies are expressed by leveraging the notions of principals. In our system, a principal is a string that 
represents a source of authority such as a user, group, role, etc. A DC label, written (S,I), consists of two 
Boolean formulas S and / over principals. Both components S and / are minimal formulas in conjunctive 
normal form (CNF), with positive terms and clauses sorted to give each formula a unique representation. 
Component S protects secrecy by specifying the principals that are allowed (or whose consent is needed) 
to observe the data. Dually, / protects integrity by specifying principals who created, vouches for, and 
may currently modify the data. 

Data may flow between differently labeled entities, but only in such a way as to accumulate additional 
secrecy restrictions or be stripped in integrity ones, not vice versa. Specifically, the C-relation for DC 
labels is defined as: 

Definition 1 (DC label Q relation) 

For any two DC labels (Si,h) and (S2,h), 

S 2 ==> Si h=> h 
E (5 2) / 2 ) 

In other words, data labeled (S\ , I\ ) can flow to an entity labeled (S2 , h ) if and only if the secrecy of the 
data, and integrity of the entity are preserved. Intuitively, the C relation imposes the restriction that any 
set of principals who can observe data afterwards must also have been able to observe it earlier. Dually, 
the integrity of the entity is preserved by requiring that the source label impose more restrictions than that 
of the destination. 

The join and meet for DC labels directly follows from the definition. The join and meet of any two 
DC labels L\ = (Si,/i) and L2 = (Si,h) are respectively: L\ UL2 = (Si AS2,I\ Vh) an d £4 = 
(S\ V5?,/i A/2), where each component of the resulting labels is reduced to CNF. 

Intuitively, the secrecy component of the join protects the secrecy of L\ and L2 by specifying that 
both set of principals, those appearing in S\ and those in S2, must consent for data labeled S\ AS2 to be 
observed. Conversely, the integrity component of the join, I\ V I2, specifies that either principals of I\ or 
I2 could have created and modify the data. Dual properties hold for the meet L\ flZ^- 
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We note that our implementation of DC labels forms a bounded lattice. The least restrictive component 
corresponds to the Boolean value True; the most restrictive component corresponds to the Boolean value 
False. These interpretations allow for a sound definition of the top T and bottom _L elements for the DC 
label lattice: T = (False, True), and _L = (True, False). Additionally, in our model, public entities have 
the default, or empty label, L pu b = (True, True). It is intuitive that data labeled (S,I) can be written to 
a public network with label Lp U b, only with the permission of a set of principals satisfying the Boolean 
formula S. Conversely, data read from the network can be labeled (S,I) only with the permission of a set 
of principals satisfying /. 



3.2 DC Labels in XChair 

We now describe the data structures and the role of DC labels (from now on just labels) in A Chair. 
Intuitively, the A Chair API provides administrators and reviewers with functions for querying review 
entries and modifying user accounts. Hence, AChair is implemented as a state monad RevLIO (whose 
value constrctor RevLIOTCB is not exported to untrusted code) that stores information on reviews and 
users, with LIO as the underlying monad. 

The AChairsystem relies on two principal types corresponding to papers and reviews. We identify 
papers and reviews according to the unique paper identifier/number. As such, for the zth paper the principal 
associated with the paper is P„ while the principal associated with the corresponding review is J?,-. 



Review entries A review entry is defined as a record consisting of a paper number, a reference to the 
corresponding paper, and a reference to the shared review 'notebook' . For simplicity, all reviewers append 
their review to the same review notebook. The type for such entries is: 

data ReviewEnt = ReviewEnt { paperld : : Id — Paper number 

, paper : : DCRef Paper — Paper content 
, review : : DCRef Review } — Notebook 

where DCRef is a labeled reference using DC labels, i.e., type DCRef = LIORef DCLabel. Note that this 
differs from the examples of Section|2] where the reviews were simply Labeled values. 



Users A reviewer, or user, has a unique user name, password, and two disjoint sets of paper ids (in our 
implementation these are simple lists). One set corresponds to the user's conflicting papers, the second set 
corresponds to the papers the user has been assigned to review. Concretely, we define a user as value of 
type: 



data User 



User { name 

, password 
, conflicts 
, assignments 



Name — User name 

Password — Password 

[Id] — Conflicting papers 

[Id] } — Paper assigned to review 



A user is authenticated given a user name and password as credentials. Following authentication, the 
code of the reviewer, who is assigned to papers 1 , . . . ,«, is executed with the current label initially set 
to (True, R\A--- AR„), where R( is the principal corresponding to review entry i. The current clearance 
is set to T = (False, True). The secrecy component in the clearance allows the executing code to read 
any data; the integrity component of the current label allow the process to only write to assigned reviews 
(detailed below). 
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Reading and writing papers After logging in, users are allowed to read and print out any paper by 
supplying the paper id. The label of the reference paper in the ;th review entry is set to (True, Pi). 
The secrecy component does not restrict any computation from observing the paper by reading the 
reference content (the paper). However, the integrity component restricts the modification of the ;th paper 
to computations that own principal P, and can therefore run with P, in the integrity component of its current 
label. Only a trusted administrator and the paper submission code is allowed to own such principals. As a 
consequence, computations executing on behalf of a reviewer cannot modify the paper since the current 
label assigned by the trusted login procedure never includes Pj in its integrity component. 

Reading and writing reviews A reviewer's code is also allowed to access the review notebook content 
of arbitrary review entries. Once a review has been read, however, its content must not be leaked into 
another paper's review notebook. We fulfill this requirement by identifying, using labels, when a given 
piece of code reads a certain review. Concretely, we label the reference review of the /th review entry as 
(Rj, Rj). As a consequence, when a computation wishes to read the review for entry i, it must raised it 
current label so as to include the principal Rj in its components (clearance permitted). Once a computation 
has been tainted as such, it will not be able to modify the contents of another paper's review. Such tainted 
computations will have a label with principal Rj in the secrecy component (as a conjunction) and integrity 
component (as a disjunction). Consider, for instance, a computation performing a review of paper i such 
that the current label is L, = (Rj, Rj). If the computation subsequently reads a different review labeled 
Lj = (Rj, Rj}, the current label is set to L = (Rj ARj, Ri VRj). To write to the either review i or j it 
must be that the current label flows to the review labels, i.e., L Z L, or L Z Lj. It is clear that neither flow 
restrictions are satisfied, and thus such illegal writes are prevented. 

Conflicts Following the readReview examples of Section we restrict the reading, or more specifically, 
printing of a review by those reviewers in conflict with the paper. Although every user is allowed to 
retrieve a review, they cannot observe the result unless they write it to an output channel. Hence, code 
running on behalf of a user (determined after logging in) can only write to the output channel (using 
printLabelCh) if the current label L can flow to the output channel label L () . Using the set of conflicting 
paper ids, for every user, we dynamically assign the output channel label L t) = (S (l , True), where S = 
Ri A--- AR n A (R„+i V#CONFLICT) A-- - A (R N V #C0NFLICT) and Rj, z' = n+l,...,iVarethe principals 
corresponding to all the review entries in the system (at the point of the print) that the authenticated user is 
in conflict with. Here, #C0NFLICT corresponds to a principal that none of the users own (similar to Pj used 
in the labels of paper references). For each conflicting paper i, we use the disjunction Rj V #C0NFLICT 
in the channel secrecy component to guarantee that a computation tainted with Rj cannot write to the 
channel. Suppose a computation running on behalf of a reviewer in conflict with the ;th paper reads 
review Rj. In this situation, the current label is set to L = (Rj A • • • , • • •). Subsequent attempts to write to 
the output channel will be disallowed since L%L . For L Z L u to hold, there must be a clause in L () that 
implies Rj. However, when in conflict, the only clause in the secrecy component that contains Rj in the 
Ri V #C0NFLICT (and clearly Rj V #C0NFLICT => Rj does not hold). 



We loosely use the term "raise" to mean moving up the security lattice - this implies more secret, and of lower 
integrity in the DC label lattice. 



Flexible Dynamic Information Flow Control in the Presence of Exceptions 



13 



3.3 Implementation 

Having established the underlying data structures and labeling patterns, we present the A Chair API. As the 
main goal of A Chair is to demonstrate the flexibility and power of our dynamic information flow library, 
we do not extend our example to a full-fledged system; the API can, however, be used to build relatively 
complex review systems. Below, we present the details of the AChair functions, which return actions in the 
RevLIQ monad. As previously noted, this monad is a state monad with LIO as the base monad, threading 
the system users, review entries, and name of the current user through the computation. 

System administrator interface A AChair administrator is provided with several functions that dynam- 
ically change the system state. From these functions, we detail the most interesting cases below. 

► addPaper : : Paper -^RevLIO Id 

Given a paper, it creates a new review entry for the paper and return the paper id. Internally, addPaper 
uses a function similar to addReview of Section|2] 

► addUser : : Name ^-Password — i-RevLIO () 

Given a unique user name and password, it adds the new user. 

► addAssignment : : Name — >Id — i-RevLIO () 

Given a user name and paper id, it assigns the user to review the corresponding paper. The user must 
not be already in conflict with the paper. 

► addConflict : : Name ->Id ->RevLI0 () 

Given a user name and paper id, it marks the user as being in conflict with the paper. As above, it must 
be the case that the user is not already assigned to review the paper. 

► asUser : : Name -^RevLIO () -^RevLIO () 

Given a user name, and user-constructed piece of code, it first authenticates the user and then executes 
the provided code with the current label and clearance of the user as described in Section [3~2l After the 
code is executed, the current label and clearance are restored and any information flow violations are 
reported. 

Reviewer interface The reviewer, or user, composes an untrusted RevLIO computation (or action) that 
the trusted code executes using asUser. Such actions may be composed using the following interface: 

► f indPaper : : String ->RevLI0 Id 

Given a paper title, it returns its paper id, or fails if the paper is not found. 

► readPaper : : Id — i>RevLI0 Paper 

Given a paper id, the function returns an action which, when executed, returns the paper content. 

► readReview : : Id — >RevLI0 () 

Given a paper id, the function returns an action which, when executed, prints the review to the standard 
output. Its implementation is similar to the example of Section|2] except that it operates on references. 

► appendToReview : : Id— eContent— S-RevLIO () 

Given a paper id and a review content, the function returns an action which, when executed, appends the 
supplied content to the review entry. Since there is no direct observation of the current review content, 
and to avoid label creep, the function, internally, uses toLabeled. 

Figure Q] shows a simple example using the AChair API. In this example, Alice is assigned to review 
two papers. She does so by reading each paper (for the second, she also reads the existing reviews) and 
appending to the review "notebook". Bob, on the other hand, is added to the system after Alice's code is 
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module Admin where 

import Alice 
import Bob 

main = evalRevLIO $ do 

— Adding users to system 
addUser "Alice" "password" 

— Adding papers to system 

pi <— addPaper "Flexible Dynamic..." 
p2 4- addPaper "A Static..." 

— Assign reviewers 
addAssignment "Alice" pi 
addAssignment "Alice" p2 

— Executing Alice's code 
asUser "Alice" $ aliceCode 

— Adding new users to system 
addUser "Bob" "password" 

— Assign reviewers and conflicts 
addAssignment "Bob" p2 
addConflict "Bob" pi 

— Executing Bob's code 
asUser "Bob" $ bobCode 



module Alice where 

aliceCode = do 

pi <— findPaper "Flexible Dynamic..." 
p2 «- findPaper "A Static..." 
readPaper pi 

appendToReview pi "Interesting work!" 
readPaper p2 
readReview p2 

appendToReview p2 "What about adding 
new users?" 

return () 



module Bob where 

bobCode = do 

pi <— findPaper "Flexible Dynamic..." 
p2 <- findPaper "A Static..." 
appendToReview p2 "Hmm, IFC." 
readReview pi — IFC violation attempt 
— (exception raised) 

return () 



Fig. 1: An example of code using A Chair API. 

executed. Bob first writes a review for the second paper and then attempts to violate IFC by trying to read 
(and write to the output channel) the reviews of the first paper. Though his review is appended to the correct 
paper, reading the review of the first paper is suppressed. Of course, the IFC violation attempt results in 
an exception. Though in this case Bob does not catch the exception, and the exception is propagated to the 
trusted API call asUser which handles the exceptions. Note, however, that Bob can safely recover from 
such IFC violation attempts. More specifically, the line readReview pi can be replaced by: 

catch (readReview pi) 

(A_ -> writeToBobsLog "In conflict!" ) 

In this case, Bob's computation will terminate gracefully and simply write to log when he attempts to read 
the first paper's review. 



4 Formal Semantics for LIO 

This section formalizes our library for a call-by-name A -calculus extended with Booleans, unit values, 
pairs, recursion, references, exceptions, and the LID monadic operations. Figure Q] provides the formal 
syntax of the considered language. Syntactic categories v, e, and T represent values, expressions, and types, 
respectively. Values are side-effect free while expressions denote (possible) side-effecting computations. 
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Figure 1 Formal syntax for values, expressions, and types. 



Expression 



Value 



Type 



T 



e 



v 



true | false | () | / | a \ X \ x \ Xx.e \ (e,e) 

| fixe | Lb ve | (e) LI ° | X t | • 
v | e e | %i e | if e then e else e 

| let x = e in e | return e \ e »= e 

| label e e | unlabel e | toLabeled e e 

| newLIDRef e e | readLIORef e | writeLIDRef e e 

| throwLIO e | catch e e 

| lowerClre | getLabel | getClearance 

| labelOf e | labelOf Ref e 
Bool | () | T->T | (T,T) I £ 

| Labeled £ T | LIO £ T | Ref £ T | X 



Store 



(j) :Address — > Labeled £ T 



Values In the syntax category v, symbol true and false represent Boolean values. Symbol () represents 
the unit value. Symbol I denotes security labels. Symbol a represents memory addresses in a given 
store. Symbol X represents exceptions. Values include variables (x), functions (Xx.e), tuples (e,e), and 
recursive functions (fix e). Four special syntax nodes are added to this category: Lb v e, (e) LI °, X/, and 
•. Node Lb v e denotes the run-time representation of a labeled value. Node (e) L1D denotes the run-time 
representation of a monadic LIO computation. Similarly node X/ denotes the run-time representation of a 
labeled exception. Node • represents an erased value (explained in Section[5]i. We note that none of these 
special nodes appear in programs written by users and they are merely introduced for technical reasons. 

Expressions Expressions are composed of values (v), function applications (e e), pair projections (ft, e), 
conditional branches (if e then e else e), and local definitions (let x = e in e). Additionally, ex- 
pressions may involve operations related to monadic computations in the LID monad. More precisely, 
return e and e »= e represent the monadic return and bind operations. Monadic operations related to 
the manipulation of labeled values inside the LIO monad are given by label, unlabel, and toLabeled. 
Expression label e\ ei creates a labeled value that guards e^ with label e\. Expression unlabel e ac- 
quires the content of the labeled value e while in a LIO computation. Expression toLabeled e\ ei creates 
a labeled value, with label e\, of the result obtained by evaluating the LIO computation e2- Non-proper 
morphisms related to creating, reading, and writing of references are respectively captured by expressions 
newLIORef , readLIORef, and writeLIORef . LIO operations may raise exceptions by calling throwLIO 
and catch exceptions with catch. Expression lowerClr e allows lowering of the current clearance to 
e. Expressions getLabel and getClearance return the current label and current clearance of an LIO 
computation, respectively. Finally, expressions labelOf e and labelOf Ref e respectively obtain the 
security label of labeled values and references. 

Types We consider standard types for Booleans (Bool), unit (()), pairs (t,t), and function (t — > t) 
values. Type £ describes security labels. Type Labeled £ T describes labeled values of type T, where the 



16 



D. Stefan, A. Russo, J. C. Mitchell, and D. Mazieres 



Figure 2 Operational semantics for LIO (part I). 



E ::= • • • | return E | E »= e | labelOf E | labelOf Ref E 

(RETURN) (BIND-1) 

(E,£ [return v]> — ► (^[(v) 11 "]) (£,£[(X/) 110 »= «]> — ► (^[(^/H) 

(BIND-2) (CLAB) 

v^X/ / = E.lbl 



(£,£[(v) LI ° »= e]) — >■ (£,£[e v]) (E,£[getLabel]) — > (£,£ [return I]) 

(cClr) 



/= E.clr 



(£,.E[getClearance]} — > (£,£ [return /]) 
(gLabR) 



(gLab) 

(E,£[labelOf (Lb I e)}} — > (£,£[ 



e = E.0(a) 



(E,£[labelOf Ref a}) — > (E,£[labelOf e\) 



label is of type i. Type LIO £ T represents monadic LIO computations, with a result type 1 and the security 
labels of type i. Type Ref I % describes labeled references, with labels of type I, to values of type T. Type 
X describes unlabeled exception^. 



4.1 Dynamic semantics for LIO 

The LIO monad presented in Sectionals implemented as a state monad. Without loss of generality, we 
simplify the formalization and description of expressions by making the state of the monad part of a 
run-time environment. More precisely, for a given LIO computation, the symbol E denotes a run-time 
environment that contains the current label, written E.lbl, the current clearance, written E.clr, and store, 
written E.0. We represent the store as a mapping from memory addresses (a) into labeled values (Lb I e). 
A run-time environmentE and LIO computation form a configuration (E,e). Given a configuration (E,e), 
the current label, clearance, and store when starting evaluation e is given by E.lbl, E.clr, and E.0, 
respectively. 

The relation (E, e) — > (E',e') represents a single evaluation step from expression e, under the run-time 
environment E, to expression e' and run-time environment E' — we say that e reduces to e' in one step. We 
write — >* for the reflexive and transitive closure of — >. The evaluation relation is defined in terms of a 
structured operational semantics via evaluation contexts ( Felleisen, 1988| ). 

The reduction rules for standard A -calculus are self-explanatory and presented in Appendix lAl More 
interestingly, Figures |2] and [3] present the non-standard evaluation contexts and reduction rules for our 
language. These rules guarantee that programs written using our approach fulfill non-interference, i.e., 
confidential information is not leaked, and confinement, i.e., a computation cannot access data above its 
clearance. 



For simplicity, we assume the set of exceptions is limited to a single type. 
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Figure 3 Operational semantics for LIO (part II). 



E ::= ••• label E e | unlabel E | toLabeledZs e | newLIORef E e 

| readLIORef E | writeLIORef E e | throwLIO E | catch E e | lowerClr E 

(Lab) (unLab) 

E.lbl CZ □ E.clr /' = E.lbl U/ E.clr l! = £[lbl >->• l'} 



(E,£[label/ e\) — > (E,£[return (Lb I e)]) (E,£ [unlabel (Lb I e)]) — > (£',£ [return e\) 

(toLab-1) 

E.lbl C/ □ E.clr 

(E,e) — >* (E',(v) LI °) E'.lblC/ E" = E'[lbli->- E.lbl, clrH' E.clr] 
(E,£[toLabeled/ e]) — > (E",£[label / v]) 

(toLab-2) 

E.lbl Ql □ E.clr 

(E,e) — >* (E',(v) LID ) E'.lblg/ E" = E'[lblh-> E.lbl, clr^E.clr] /" = /UE'.lbl 
(E,E[toLabeled/ e]) — > (E",£[label IX[,]) 



(nRef) 

E.lbl HI □ E.clr E' = E.0[ai-^Lb/e] 
(E^newLIORef / e]) — > (E',£ [return a]) 



afresh 



(rRef) 

E.0(a)=Lb/e /' = E.lbl Ul E.clr E' = E[lbl i-> /'] 

(E,E [readLIORef a]) — > (E',£[returne]) 

(wRef) 

E.0(a)=LbZe E.lbl C Z C E.clr E' = E.0[a ^ Lb I e'\ 
(E^writeLIORef a e']) — > (E',£[return ()]) 

(THROW) (CATCH- 1) 

/ = E.lbl /'= E.lbl U/ E.clr E' = E[lbl n- /'] 

(E,£[throwLIOX]} — > (E,£[(X,) LID ]) (E,£[catch (X,) LID e]) — > (Z',E[eX}) 

(CATCH-2) (LWCLR) 

v^X, E.lbl □/ C E.clr E' = E[clr h-> /] 



(E,£[catch (v) LID e\) — > (E,£[(v) LID ]) (E,£[lowerClr /]) — > (E',£[return ()]) 



Rules in Figure[2]are self-explanatory, e.g., the evaluation rules for return and (>>=) are standard and 
labeled exceptions are propagated by (»=) (rule (BIND-1)). Rule (Lab) of Figure[3]generates a labeled 
value if and only if the label is between the current label and clearance of the LIO computation. Rule 
(unLab) provides a method for accessing the content e of a labeled value Lb / e in LIO computations. 
When the content of a labeled value is retrieved and used in an LIO computation, the current label is raised 
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(E' = E[lbl M- /'], where /' = E.lbl U /), capturing the fact that the remaining computation might depend 
on e. Of course, the current label should not exceed clearance (/' C E.clr). 

The reduction of toLabeled deserves some attention. Expression toLabeled I e is used to execute a 
computation e to completion^ ((E,e) — >* (E', (v) L1D )) and wrap the result v into a labeled value whose 
label is /. Specifying label I is the responsibility of the programmer. We note, however, that the label 
I needs to be an upper bound on the current label for the evaluation of computation e (E'.lbl C /), a 
restriction imposed in (toLab-1). The reason for this is due to the fact that security labels are protected 
by the current label, effectively making them public information accessible to any computation within 
scope (see rules (gLab) and (gLabR)). As a consequence, a toLabeled that does not impose an upper 
bound on the sensitivity of the data observed by e is susceptible to attacks. To illustrate this point, consider 
a computation with current label is Iq, that takes two (confidential) labeled values with respective labels 
l\ and U such that /,■ % Iq,i = 1,2. (Recall that the current label and clearance of a given LIO computation 
can be changed dynamically.) Further, suppose that toLabeled does not take an upper-bound on the 
computation's observations. Directly, the following program can be used to leak sensitive information: 

leak 1V1 1V2 = do — Initial label L cul - = Iq 

1V3 toLabeled $ do — Label of 1V3 may be: 

vl 4- unlabel 1V1 — Read first value, raise label to L cul - = l\ 

if vl then return True — If value is, leave current label L cur = l\ 
else unlabel 1V2 — Otherwise, the current label to L cur = I2 
return (labelOf 1V3) — Can be l\ or I2 

Note that, if the returned value of the inner computation can have the label l\ or I2 (remember that 
labels are effectively public information), information is directly leaked! Hence, to prevent such leaks, 
programmers must provide an upper-bound on the current label obtained when e finishes computing. 
Since our approach is dynamic, flow-sensitive, and sound, this may require non-trivial static analysis in 
order to automatically determine the label for each call of toLabeled ( |Russo & Sabelfeld, 2010| ). 

However, if the inner computation does read data more sensitive than /, such that the end current label 
E'.lbl % I, rule (TOLab-2) specifies that an exception labeled with the join of the upper-bound / and E' 
must be raised when performing an unlabel — hence, we return a labeled value that encloses an exception. 
Note that an exception is not raised at the point of evaluating toLabeled, but rather when the labeled 
value is unlabeled, and the current label is raised (see (UNLAB)). 

When creating a reference, newLIORef / e produces a labeled value that guards e with label / and 
stores it in the memory store (E' = E.0 [a H> Lb / e\). The result of this operation is the memory address a 
(return a). Observe that references are created only if the reference's label (/) is between the current label 
and clearance label (E.lbl C I C E.clr). As in (Lab), the restriction / C E.clr assures that programs 
cannot manipulate or access data beyond their clearance. Section [5] further details such confinement 
guarantees. Rule (rRef) obtains the content e of a labeled value Lb / e stored in at address a. This rule 
raises the current label to the security level I' (E' ~ E[lbl M> I'] where I' = E.lbl U I). As in the previous 
rule, (rRef) enforces that the result of reading a reference is below the clearance (/' C E.clr). Finally, rule 
(wRef) updates the memory store with a new value for the reference (E' = E.0 [a \-> Lb I e']) as long as the 
label of the reference is above the current label and it does not exceed the clearance (E.lbl C / C E.clr). 



By using big-step semantics instead of an evaluation context of the form toLabeled / E, the rules do not need 
to rely on the use of trusted primitives or a stack for (saving and) restoring the current label and clearance when 
executing toLabeled. 
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If considering E.lbl as a dynamic version of the pc the restriction that the label of the reference must be 
above the current label (E.lbl C /) is similar to the one imposed by ( Pottier & Simonet, 2002| l. 

Throwing and catching exceptions is standard. An LIO computation may raise an exception according 
to rule (THROW). The label of the raised exception is set to the current label. To handle exceptions raised 
in a computation e\, a computation can execute the computation as catch e\ e2, where ei corresponds 
to the exception handler. If no exception is raised, then rule (CATCH-2) simply propagates the value. 
However, if an exception is raised, and according to rule (CATCH- 1 ), the current label is raised (clearance 
permitting) to the label of the exception and the exception handler is applied to the unlabeled exception. 
It is important to note that although our formalization of exceptions is limited to a single type, exceptions 
in LIO can encode information, similar to our encoding of the current label at the point of the throw. 

Rule (lwClr) allows a computation to lower the current clearance to I. This operation is particularly 
useful when trying to contain the access to some data as well as the effects produced by computations 
executed by toLabeled. Rules (cLab) and (cClr) obtain the current label and clearance from the run- 
time environment. Finally, rules (gLab) and (gLabR) return the labels of labeled values and references. 
Observe that, regardless of the current label and clearance of the run-time environment, these two rules 
always succeed — hence "labels are public". 

Addressing IFC violation attempts Most of the evaluation rules in Figure[3]have a premise that imposes 
an information flow restriction. For example, rule (Lab) imposes the restriction that no labeled values may 
be labeled with a label below the current label or above the current clearance. As previously mentioned, 
rather than imposing that the evaluation of a misbehaving program gets "stuck", we allow untrusted code 
to recover by throwing a monitor exception. Specifically, we introduce a "violation rule" for each rule 
that consists on the rule's premise being negated and always evaluating to a throwLIO. For example, the 
violation rule for rule (Lab) is given by: 

(-.Lab) 

-.(E.lbl C/ CE.clr) 
(E,£ [label / e\) — > (E,£[throwLIOX]) 

The remaining rules are similar and omitted for brevity. 



4.2 Static semantics for LIO 

Figure |4] shows the typing rules for a subset of the terms and expressions; the remaining rules are shown 
in Appendix [A] The typing rules are standard and we therefore do not describe them further. We note, 
however, that, unlike previous work ( |Russo et al., 200 8 ; Devrie se~& Piessens, 201 l| l, we do not require 
the use of any sophisticated features from Haskell's type-system, a direct consequence of our dynamic 
approach. 



5 Soundness 



In this section we show that LID computations satisfy two security policies: non-interference and confine- 
ment. Non-interference shows that secrets are not leaked, while confinement establishes that certain pieces 
of code cannot manipulate or have access to certain data. The latter policy is similar to the confinement 
policies presented in (Leroy & Rouaix, 1998 Banerjee & Naumann, 2005 1. 
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Figure 4 Typing rules for subset of terms and expressions. 



hi 



T(fl) = Labeled £ X 
T h a : Ref I X 

rhe-.e rhx:x 

r h X e : x 

The: Labeled £ x 
T h unlabel e : LIO £ T 



rhx-.x 



rh, 



r h e 2 : T 



The: T 



rh, 



r h e 2 : T 



r h Lb e\ e 2 : Labeled £ X T h (e) LID : LIO £ X 

T\-ei:£ rhe 2 :T 
T h label e\ e 2 : LIO £ (Labeled £ t) 

rhei:^ rhe 2 :LI0^T 
T h toLabeled e x e 2 : LIO £ (Labeled £ x) 

The: Ref £ X 



T h newLIORef e x e 2 : LIO £ (Ref £ t) 

rhei:RefiT rhe 2 :T 
T h writeLIORef ej e 2 : LIO ^ 

rhei:LI0^T rhe 2 :X->LI0£T 



T h readLIORef e : LIO t X 

The:X 
r h throwLIO e : LIO £ X 



T h catch ei e 2 : LIO £ X Y h lowerClr e : LIO ^ () 

The:Lb£T r h e : Ref £ X 

h getClearance : LIO £ £ 



getLabel : LIO £ £ 



T h labelOf e : £ 



T h labelOf Ref e : £ 



5.1 Non-interference 

As in ( |Li & Zdancewic, 2010[ |Russo et ai, 20 08 ), we prove the non-interference property by using the 
technique of term erasure. Intuitively, data at security levels where the attacker cannot observe information 
can be safely rewritten to the syntax node •. For the rest of the paper, we assume that the attacker can 
observe data up to security level L. The syntactic term •, denoting an erased expression, may be associated 
to any type (recall Figure |9). Function El is responsible for performing the rewriting for data at security 
level not lower than L. In most of the cases, the erasure function is simply applied homomorphically (e.g., 
£i(if E then e else e') = if £l(E) then £z.(e) else £i(e')). In the case of data constructors, it is 
simply the identity function. The definition of £i for expressions and evaluation contexts are shown in 
Appendix|B] Figure [5] shows the definition of £i for terms, configurations, and bind. The three interesting 
cases for this function are when £i is applied to a labeled value, a given configuration, or bind. In such 
cases, term erasing could indeed modify the behavior of the program. A labeled value is erased if the label 
assigned to it is abov^L (£i(Lb / e) = Lb / •, if / % L). Similarly, the computation performed in a certain 
configuration is erased if the current label is above L (£/,((£, e)) = (£l(E), •) if E.lbl % L). Finally, if El 
is applied to a bind-expression where the action evaluates to a labeled exception with label / and / % L, 
then the expression is fully erase to (») LI °. 



5 We loosely use the word "above" to mean %, since labels may not be comparable. 
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Figure 5 Erasure function for terms, memory store, configurations and bind-expression. 
£ L (true) = true £ L (false) = false £/,(())=() E L (l) = I E L (a) = a E L (x) = . 
e L {Xx.e) =Xx.e L (e) £ L {{e,e)) = (e L (e) , e L (e)) 



. , . \ Vol* I XL 

e L Lb / e) = { , . . 7 . 

^ Lb/£L(e) otherwise 

eiJ£4) = {(x,e L {I,4(x)):x E dom(E.0)} 
£ L (E)=E[</>^£ L (E.</>)] 



£ L (fix e) = fix£ L (e) 
e L ((eD = (e L (e)r e L (.) = . 



e L (X)=X 
e L (ei »=e 2 ) -- 



edx) = { • 1%L 

\ X[ otherwise 



E.lbl %L 
(e)) otherwise 



(•) 



£l(ci) >>= Sl^i) otherwise 



e x = (Xi) Lla and / %L 



Following the definition of the erasure function, we introduce a new evaluation relation — >i as follows: 



Definition 2 ( — >i) 



(E, e ) -> (E', e '} 



(E, e ) ^ i£i ({E', e ')) 

Expressions under this relationship are evaluated in the same way as before, with the exception that, 
after one evaluation step, the erasure function is applied to the resulting configuration, i.e., run-time 
environment and expression. In that manner, the relation — >i guarantees that confidential data, i.e., data 
not below level L, is erased as soon as it is created. We write — >* L for the reflexive and transitive closure 
of — > L . 

Most results that prove non-interference pursue the 
goal of establishing a relationship between — >* and — >* L 
through the erasure function, as highlighted in Figure [6] 
Informally, the diagram establishes that erasing all secret 
data, i.e., data not below L, and then taking evaluation 
steps in — >l is the same as taking steps in — > and then 
erasing all the secret values in the resulting configuration. 
Observe that if information from some level above L is 
leaked by e, then erasing all secret data and then taking 
evaluation steps in — >i might not be the same as taking 
steps in — > and then erasing all the secret values in the resulting configuration. 

For simplicity, we assume that the address space of the memory store is split into different security 
levels and that allocation is deterministic. In that manner, the address returned when creating a reference 
with level / depends only on the references with level / already in the store. These assumptions are valid 
in our language since, similar to traditional references in Haskell, we do not provide any mechanisms for 



el 



el 



Fig. 6: Simulation between 



and 
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deallocation or inspection of addresses in the API. However, when memory allocation is an observable 
channel, the library could be adapted in order to deal with non-opaque pointers ( |Hedin & Sands, 2006| ). 

We start by showing that the evaluation relationships — > and — >i are deterministic. Firstly, however, 
we note that e = e' means syntactic equality between expressions e and e' and equality between run-time 
environments, written E = E', is defined as the point-wise equality between mappings E and E'. 

Proposition 1 (Detenninacy of — >) 

► For any expression e and run-time environment E such that (E,e) — > (E',e"), there is a unique 
term e' and unique evaluation context E such that e =E[e']. 

► If (E,e) — ► (E',e') and (E,e) — ► (E",e"), then e' = e" and E' = £". 

Proof 

By induction on expressions and evaluation contexts. □ 
Proposition 2 (Detenninacy of — >£) 

If (E,e) — > L (E',e') and (E,e) — > L (E",e"), then e' = e" and E' = E". 
Proof 

From Proposition[T]and definition of El. □ 

The following proposition shows that the erasure function is homomorphic to the application of evalu- 
ation contexts and substitution as well as that it is idempotent. 

Proposition 3 (Properties of erasure function) 

1. e L {E[e}) = £ L (E)[e L (e)} 4. e L (e L (E)) = e L {E) 

2. E L ([e 2 /x]e l ) = [e L (e 2 )/x]e L (e l ) 5. e L (e L (Z)) = e L (E) 

3. e L (e L (e)) = e L {e) 6. e L (e L ((E, e ))) = e L «£,e» 

Proof 

Most cases follow by induction on expressions and evaluation contexts, see Appendix IClfor details. □ 

The next lemma establishes a simulation between — > and — >l for expressions that do not execute 
toLabeled. 

Lemma 1 (Single-step simulation without toLabeled) 

If r h e : X and (E,e) — > C^\ e ') where toLabeled is not executed, then T h e' : T and ££((E,e)) — >i 

£L((E', e '))- 

Proof 

Part of the lemma shows subject reduction, which is proved by showing that a reduction step does not 
change the types of references in the store E.0 and then applying induction on the typing derivations. 
The simulation follows by induction on evaluation contexts and case analysis on terms and expressions. 
Details are presented in Appendix ICl □ 

Using this lemma, we then show that the simulation is preserved when performing several evaluation 
steps. 

Lemma 2 (Simulation for expressions not executing toLabeled) 

If The : T, (E,e) — >* (E',e') where there are no executions of toLabeled, then rh e' : T and ej,((E,e)) — ! 

£l(£V))- 

Proof 
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By induction on — > and application of LemmaQ] □ 

The reason for highlighting the distinction between expressions executing toLabeled and those not 
executing it is due to the fact that the evaluation of toLabeled involves big-step semantics (recall rules 
(TOLab-1) and (toLab-2) in Figure|3]l. However, the next lemma shows the simulation between — ►* 
and — >1 for any expression e. 

Lemma 3 (Simulation) 

If The: rand (E,e) — >* (E',e') then £ L ((E,e)) — >* L £ L ((E',e'))- 
Proof 

Lemma|2]shows the multi-step simulation for expressions that do not execute toLabeled. Thus, to show 
the general multi-step simulation, we first prove that toLabeled preserves the simulation by induction 
on the number of executed toLabeled. The general simulation follows directly. The interested reader is 
referred to AppendixICl □ 



Figure 7 L-equivalence for expressions. 


e k l e / CL 


IgL 


Lb I e w L Lb / e' 


Lb I e « L Lb / e' 



We define L-equivalence between expressions. Intuitively, two expressions are L-equivalent if they are 
syntactically equal, modulo labeled values whose labels do not flow to L. We use to represent in- 
equivalence for expressions. Figure [7] shows the definition for labeled values. Considering the simple 
lattice: LCMCH and an attacker at level L, it holds that Lb H 8 ss L Lb H 9, but it does not hold that 
Lb L 2 w L Lb L 3 or Lb H 8 «l Lb M 8. Recall that labels are protected by the current label, and thus 
(usually) observable by an attacker — unlike the expressions they protect, labels must be the same even if 
they are above L. The rest of «l is defined as syntactic equality between constants (e.g., true true) or 
homomorphisms (e.g., if e then e\ else e2 ~l if then e\ else e' 2 if e k l e 1 ', e\ «i e\, and e?_ xi L e' 2 ). 

Since our language encompasses side-effecting expressions, it is also necessary to define L-equivalence 
between memory stores. Specifically, we say that two run-time environments are L-equivalent if an at- 
tacker at level L cannot distinguish them: 

Definition 3 (L-equivalence for stores) 

/CLV/'CL Va.E.0(a) = Lb / e « L L'.<j>(a) = Lb /' e 
Z.0 « L £'.0 

Note that the L-equivalence ignores the store references with labels above L. Similarly, we define L- 
equivalence for configurations. 

Definition 4 (L-equivalence for configurations) 

eK, L e' L.(j> & L T/ E.lbl = E'.lbl E.clr = E'.clr E.lblCL 

M « L <eV> 

E.0« l E'.</> E.lblgL E'.lblgL 
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In the above definition, it is worth remarking that we do not require f«£ for expressions when the current 
label does not flow to L. This omission comes from the fact that e and e' would be reduced to • when 
applying our simulation between — >* and — >* L (recall Figure |5}. 

The next theorem shows the non-interference policy. It essentially states that given two inputs with 
possibly secret information, the result of the computation is indistinguishable to an attacker. In other 
words, there is no information-flow from confidential data to outputs observable by the attacker. 

Theorem 1 (Non-interference) 

Given a computation e (with no •, ( ) LI °, Lb, or X t ) where The: Labeled t x — ► LIO I (Labeled I t'), 
environments Ei and E 2 where = £2.^ =0, security label /, an attacker at level L such that / C L, 
then 

Veie 2 -(r h e t : Labeled £ T) i= i )2 A (e; = Lb / e-)<=l,2 A ~l (^2,62) 

A (E 1>e ei ) ^* (^.(vjD A (Ia,e e 2 ) (E 2 , (v 2 ) uo ) 
=► (Ei,(vir>«i<4,(v 2 r> 

Proo/ 

From Lemma|3]and determinacy of — The details are shown in AppendixICl □ 

Observe that even though we assume that the input labeled values e\ and e 2 are observable by the attacker 
(Z C L), they might contain confidential data. For instance, e\ could be of the form Lb / (Lb /' true) where 
I'gL. 

5.2 Confinement 

In this section we present the formal guarantees that LIO computations cannot modify data below their 
current label or above their current clearance. 

We start by proving that the current label of an LIO computation does not decrease. 

Proposition 4 (Monotonicity of the current label) 
IfTheirand (E,e) — >* (I',e'), then I.lbl □ E'.lbl. 

Proof 

By induction on expressions, evaluation contexts, and reduction rules. □ 

Similarly, we show that the current clearance of an LIO computation never increases. 

Proposition 5 (Monotonicity of the current clearance) 
If The: rand (E,e) — >* (E',e'), then E'.clr C E.clr. 

Proof 

By induction on expressions, evaluation contexts, and reduction rules. □ 

Proposition|4]and|5]are crucial to assert that once an LIO computation reads confidential data, it cannot 
lower its current label to leak it. Similarly, a computation should not be able to arbitrarily increase its 
clearance; doing so would allow it to read any data with no access restrictions. 

Before delving into the confinement theorems, we first define a store modifier that removes all store 
elements with a label that does not flow to 

Definition 5 (Label-based reference-cell removal) 
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Modifier (E.0)|/ retains all the labeled references with a label below /, usually the current label: 

(E.0) 4 , = E.0 \ {(a, Lb I' e) : a € dom(E.0) A/' % 1} 
And, dually, a store modifier that removes all store elements below a given clearance I. 
Definition 6 (Clearance-based reference-cell removal) 

(E.0) t/ = E.</> \ {(a,Lb l' e) :a £ dom(E.0) A I g l'} 

This store modifier retains all the labeled references with a label that is not below /, usually the current 
clearance. We now present the first confinement theorem. 

Theorem 2 (Store confinement) 

Given labels / and l c , a computation e (with no •, a, ( ) LI °, Lb, or X)i) such that The: LIO I X, and 
environment E[lbl i-> /, clr i-> l c ] where I C l c , then 

(E, e ) — >* (£»"") => (E.</>) ;/ = (E'.0) ;/ A(E.0) t/c = (E'» t/c 

Proo/ - 

By contradiction on creating and modifying labeled references with labels not boded by the current label 
and clearance, using Propositions [4] and [5] □ 

Intuitively, this theorem states that no new references with a label not bounded by the initial current label 
and current clearance can be created. And, computation e is confined to modifying references between / 
and l c . 

Our second confinement theorem states that a return labeled value comes either from some part of the 
store (recall that labeled values can be nested) or might be computed when its security level is between 
the current label and clearance. 

Theorem 3 (Labeled creation confinement) 

Given labels I, l c , and /,,, a computation e (with no •, a, ( ) LID , Lb, orX//) where The: LIO I (Labeled £ t), 
and environment E[lbl M> I, clr n> l c ] such that I C l c , then 

(E,e) — >* (E',(Lb/ v ei) LIC > => IQI V C/ c v3(a,Lb/i e[) eE.0.Lb/ v ei ee\M\ Efc 

Here, operator e is defined as the syntactic appearance of the left-hand expression into the right-hand side 
operand. 

Proof 

By induction on expressions and evaluation contexts and using Propositions|4]and|5] □ 



6 Related Work 

Heintze and Riecke pieintze & Riecke, 1998| l consider security for lambda-calculus where lambda-terms 
are explicitly annotated with security labels, for a type-system that guarantees non-interference. One 
of the key aspects of their work consists of an operator which raises the security annotation of a term 
in a similar manner to our raise of the current label when manipulating labeled values. Similar ideas of 
floating labels have been used by many operating systems, dating back to the High- Water-Mark security 
model dLandwehr, 1981| l of the ADEPT-50 in the late 1960s. Asbestos ( |Efstathopoulos et al, 2005| ) first 
combined floating labels with the Decentralized label model (Myers & Liskov, 19971. 
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Abadi et al. ( |Abadi et al, 1999) 1 develop the dependency core calculus (DCC) based on a hierarchy of 
monads to guarantee non-interference. In their calculus, they define a monadic type that "protects" (the 
confidentiality of) side-effect-free values at different security levels. Though not a monad, our Labeled 
type similarly protects pure values at various security levels. To manipulate such values, DCC uses a 
non-standard typing rule for the bind operator; the essence of this operator, in a dynamic setting with 
side-effectful computations, is captured in our library through the interaction of of Labeled, unlabel, 
and LIO. 

Tse and Zdancewic ( |Tse & Zdancewic, 2004) 1 translate DCC to System F and show that non-interference 
can be stated using the parametricity theorem for System F. The authors also provide a Haskell implemen- 
tation for a two-point lattice. Their implementation encodes each security level as an abstract data type 
constructed from functions and binding operations to compose computations with permitted flows. Since 
they consider the same non-standard features for the bind operation as in DCC, they provide as many 
definitions for bind as different type of values produced by it. Moreover, their implementation needs to 
be compiled with the flag -f allow-undecidable-instances, in GHC. Our work, in contrast, defines 
only one bind operation for LIO, without the need for such compiler extensions. 

Harrison and Hook show how to implement an abstract operating system called separation kernel 
(Harrison, 2005 ). Programs running under this multi-threading operating system satisfy non-interference. 
To achieve this, the authors rely on the state monad to represent threads, monad transformers to present 
parallel composition, and the resumption monad to achieve communication between threads. Conse- 
quently, non-interference is enforced by the scheduler implementation, which only allow signaling threads 
at the same, or higher, security level as the thread that issued the signal. The authors use monads differently 
from us; their goal is to construct secure kernels rather than provide information-flow security as a library. 
Our library is simpler and more suitable for writing sequential programs in Haskell. Extending our library 
to include concurrency is stated as a future work. 

Crary et al. (Crary et al., 2005 1 design a monadic calculus for non-interference for programs with mu- 
table state. Similar to our work, their language distinguishes between term and expressions, where terms 
are pure and expressions are (possibly) effectful computations. Their calculus mainly tracks information 
flow by statically approximating the security levels of effects produced by expressions. Compared to 
their work, we only need to make approximations of the side-effects of a given computation when using 
toLabeled; the state of LIO keeps track of the dynamic security level upper bound of observed data. 
Overall, our dynamic approach is more flexible and permissive than their proposed type-system. 

Pottier and Simonet ( |Pottier & Simonet, 200 2 ; Simonet, 2003) designed FlowCaml, a compiler to en- 
force non-interference for OCaml programs. Rather than implementing a compiler from scratch, and more 
similar to our approach, the seminal work by Li and Zdancewic ( |Li & Zdancewic, 2006) > presents an 
implementation of information-flow security as a library, in Haskell, using a generalization of monads 
called Arrows ( Hughes, 2000 1. Extending their work, Tsai et al. ( chung Tsai et al. , 2007 1 further consider 
side-effects and concurrency. Contributing to library-based approaches, Russo et al. ( |Russo et al., 2008) > 
eliminate the need for Arrows by showing an IFC library based solely on monads. Their library defines 
monadic types to track information-flow in pure and side-effectful computations. Compared to our dy- 
namic IFC library, Russo et al.'s library is slightly less permissive and leverages Haskell's type-system 
to statically enforce non-interference. However, we note that our library has similar (though dynamic) 
functions provided by their SecIO library; similar to unlabel, they provide a function that maps pure 
labeled values into side-effectful computations; similar to toLabeled, they provide a function that allows 
reading/writing secret files into computations related to public data. 
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Morgenstern et al. ( Morgenstern & Licata, 2010 1 encoded an authorization- and IFC-aware program- 
ming language in Agda. Their encoding, however, does not consider computations with side-effects. 
More closely related, Devriese and Piessens ( |Devriese & Piessens, 201 \\ used monad transformers and 
parametrized monads (Atkey, 2006) to enforce non-interference, both dynamically and statically. How- 
ever, their work focuses on modularity (separating IFC enforcement from underlying user API), using 
type-class level tricks that make it difficult to understand errors triggered by insecurities. Moreover, 
compared to our work, where programmers write standard Haskell code, their work requires one to firstly 
encode programs as values of a specific type. 

Compared to other language-based works, LIO uses the notion of clearance. The work of Bell and 
La Padula ( [Bell & Padula, 1976[ l formalized clearance as a bound on the current label of a particular users' 
processes. In the 1980s, clearance became a requirement for high-assurance secure systems purchased by 
the US Department of Defense ( Department of Defense, 1985 1. More recently, HiStar ( jZeldovich et al, 2006| l 
re-cast clearance as a bound on the label of any resource created by the process (where raising a process's 
label is but one means of creating a something with a higher label). We adopt HiStar's more stringent 
notion of clearance, which prevents software from copying data it cannot read and facilitates bounding 
the time during which possibly untrustworthy software can exploit covert channels. 

Simultaneously to this work, Hedin and Sabelfeld have recently published a dynamic information-flow 
monitor for a core part of Javascript which handles exceptions ( |Hedin & Sabelfeld, 20 12). Their approach 
needs to explicitly mark in the code (through non-standard constructors) which exceptions are thrown 
under a secret branch. Our approach, in contrast, simple raises an exception labeled with the current label. 



7 Conclusion 

We propose a new design point for IFC systems in which most values in lexical scope are protected by a 
single, mutable, current label, yet one can also encapsulate and pass around the results of computations 
with different labels. Unlike other language-based work, our model provides a notion of clearance that 
imposes an upper bound on the program label, thus providing a form of discretionary access control on 
portions of the code. 

We prove information flow and integrity properties of our design and describe LIO, an implementation 
of the new model in Haskell. LIO, which can be implemented entirely as a library, demonstrates both the 
applicability and simplicity of the approach. We show the capabilities of the library to perform secure 
side-effects (e.g., references) as well as safely handle exceptions. Our non-interference theorem proves 
the conventional property that lower-level results do not depend on higher-level inputs - the label system 
prevents inappropriate flow of information. We also prove confinement theorems that show the effect of 
clearance on the behavior of code. In effect, lowering the clearance imposes a discretionary form of access 
control by preventing subsequent code (within that scope) from accessing higher-level information. 

As an illustration of the benefits and expressive power of this system, we describe a reviewing system 
that uses LIO labels to manage integrity and confidentiality in an environment where users and labels 
are added dynamically. Although we have use LIO for the AChair API and even built a relatively large 
web-framework that securely integrates untrusted third-party applications, we believe that changes in the 
constructs are likely to occur as the language matures. This further supports our library-based approach to 
language-based security. 
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A Standard Static and Dynamic Semantics 

For completeness, in this section, we provide the evaluation and typing rules for standard terms and 
expressions. Figure [8] defines the set of evaluation contexts and reduction rules for standard constructs 
in our language. Substitution ([ei/x] e 2 ) is defined in the usual way: homomorphic on all operators and 
renaming bound names to avoid captures. Figure|9]describes the typing rules for terms; FigurefTOldescribes 
the typing rules for expressions. 

Figure 8 Operational semantics for standard terms. 



E ::= [•] | Lb E e \ E e | Tti E | if E then e else e 

(I,£[(Ax. ei ) e 2 }) — > (E,£[[e 2 /x] ei ]) 
(Z,£[fixe]) — > {L,E[e (fixe)]) 
(Z,E[m (ei.ea)])— 

(E,£[if true then e\ else e 2 ]) — > t£,E\e\\) 
(E,£[if false then e\ else e 2 ]) — > (E,£[e2]) 
(L,E[letx = ei ine 2 ]) — > (E,£[[ei/*]e 2 ]) 



Figure 9 Typing rules for standard terms. 



r(x)=T rfjc^ nl he: T 2 

h true: Bool h false : Bool h () : () 



r h x : T T h Xx.e : Ti — > T 2 

r h ei : Ti The 2 :T 2 r h e : T — > T The:T 



Th (e h e 2 ) : (Ti,T 2 ) rhfixe:r r h~ (e) LID : LIO £ T 



rh • : T 



Figure 10 Typing rules for standard expressions. 



r h ei : Ti -> T 2 rhe 2 :T! The:(Ti,T 2 ) rhei:Bool T h e 2 : T T h e 3 : T 
r h e\ e 2 : T 2 T h 7T/ e : T; T h if ei then e 2 else e 3 : T 

rhei:Ti r[x \-t Ti] I- e 2 : T 2 The:T 

r h let x = ei in e 2 : T 2 T h return e : LIO f T 

r h ei : LIO I T\ r h e 2 : n -)• LIO £ T 2 
Thei »=e 2 :LI0^T 2 
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B Erasure function 

In this section we define the erasure function £/,, introduced in Section [5] for the remaining expressions 
(Figure [TTTi and evaluation contexts (Figure [TZt. 

Figure 11 Erasure function for expressions. 

e L (e e) = e L (e) e L (e) £ L (7T ; e) = %i £ L (e) 

e^(if e then e else e) = if £z,(e) then £/,(e) else £z.(e) 
£i(let x = e in e) = let x = £z.(e) in £l(c) £i(returne) = return £z.(e) 

£L(label e e) ~ label £i(e) £z.(e) ^(unlabel e) = unlabel £z,(e) 

£i(toLabeled e e) = toLabeled £l(<?) £l(<0 £l (newLIORef e e) = newLIORef £z.(e) £l(<?) 

£L(readLIORef e) = readLIDRef £ L (e) £L(writeLIORef «) = writeLIORef £ L (e) £ L {e) 
£i(throwLID e) = throwLIO £l(c) ^(catch e e) = catch £i(e) £l(c) 

££(lowerClr e) = lowerClr £i(e) £i(getLabel) = getLabel 

£i(getClearance) = getClearance ^(labelOf e) = labelOf £z,(e) 

£ L (labelOf Ref e) = labelOf Ref £ L {e) 



Figure 12 Erasure function for evaluation contexts. 

£ L (Lb£e) = Lb£ L (£)£ L (e) £ L {E e) = £ L (E) £ L {e) e L {m E) = m £ L (E) 

£i(if E then e else e) = if £l(E) then £t{e) else £i(e) £/,(return E) = return Bl(E) 

£ L (E »= e) = £l{E) »= £l(<?) £ L (label E e) = label S L {E) £ L {e) 

£i(unlabel E) = unlabel £l(E) ^(toLabeled E e) = toLabeled £l(E) £/.(e) 

£ L (newLIORef E e) = newLIORef £l{E) £i{e) £ L (readLIORef E) = readLIDRef £l{E) 

£ L (writeLIORef E e) = writeLIORef £l{E) £i{e) £ L (throwLI0 E) = throwLIO £l{E) 

£i(catch E e) = catch £l(E) £l(<?) ^(lowerClr E) = lowerClr £l(E) 

£ L (labelOf E) = labelOf e L (E) £ L (labelOf Ref E) = labelOf Ref e L (E) 
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C Detailed proofs 



In this section, we provide expand the proof details for the results in Section[5] 




4. £ L (£l(£)) = £l(E) 

5. £l(£l(£)) = £l(£) 
6. 



Proof 

All follow from the definition of the erasure function El, and induction on expressions and evaluation 
contexts, 

1. By induction on expressions and evaluation contexts. We show several cases of the base case 
analysis on evaluation contexts. 



(a) LetE := Lb [] eo, it follows that El(E) := Lb [] £z.(eo), and g L (£[e]) = £z.(Lbe eo) = Lb£ L (e) £z,(eo) = 



(b) Let E :=[] e , it follows that e L (E) := [ ] £ L (e ), and e L (E[e]) = £ L (e e ) = e L (e) £ L (e ) = 



(c) LetZs := m [], it follows that £/.(£) := %i [], and £ L (E[e]) = £l(7T/ e) = jfy £i(e) = ez,(£ , )[et(e)]. 

2. By expansion £i([e2A]ei) = £L((Ax.ei) e2)>fr° m which we have ^(Ajc.ei) £i(e2) = [£L(e2)A]£i(ei). 

3. Directly from definition of the erasure function and induction on expressions. 

4. Directly from definition of the erasure function and induction on expressions and evaluation con- 
texts. 

5. Directly from definition of the erasure function on stores and property 3 above. 

6. Directly from definition of the erasure function on configurations and properties 3 and 5, above. 



Lemma 1 (Single-step simulation without toLabeled) 

If r h e : t and (E,e) — > where toLabeled is not executed, then r h e' : T and £/,((E,e)) 



Part of the lemma shows subject reduction, which is proved by showing that a reduction step does not 
change the types of references in the store E.0 and then applying induction on the typing derivations. 

It remains then to show the simulation, which follows by induction on evaluation contexts and cases 
analysis on terms and expressions. For clarity, we omit the environment in cases where it is not essential. 
Unless otherwise stated, we assume that E.lbl CLE E.clr, the proof for the case where L is below the 
current label is straight forward since the El erases any expression in a configuration to a hole. Conversely, 
the case where L is above the current clerance is identical to the case where L is equal to the current 
clearance. 

We show the simulation for several exemplary /interesting cases, the remaining cases follow similarly. 



£ L (E)[e L {e) 



£L(E)[£ L (e)}. 



□ 



£l«EV}). 



Proof 
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► Case E[{Xx.e\) e 2 ] — > E[[e 2 /x]e{\: 

e L (E[(Xx.ei) e 2 }) = e L (E)[e L {{Xx.ei) e 2 )} 
= e L (E)[(Xx.e L ( ei )) e L (e 2 )} 
— > L E L (e L {E)[ [e l (e 2 ) I A E L (ci )]) 

= E L {E L {E))[E L {\£ L {e 2 )/x]£ L {e{))] 

= e L (E)[e L {[e L {e 2 )/x]e L (e l ))} 

= e L {E)[[e L {e 2 )/x]e L (e 1 )] 

= e L {E)[e L ([e 2 /x}ei)] = e L (E[[e 2 /x]ei}) 

by Proposition^ 

► Case (E, £ [return v]) — ► (E,£[(v) L1D ]}: 
— E.lbl CL: 

£L ((E,£[returnv])) 
= (e L (E),e L (£ [return v])) 
= (£ L (E),e L (£)[returne L (v)]) 
^ L£L (( £L (E), eL (£)[( ei (v))-]}) 
= ( £L (E), £i (£)[( £i (v))-]) 
= ( £L (E), £L (£)[ £i ((vD]) 

= ( £l (E), £l (£[(vH)) = £L ((E,£[(vn» 
by definition of El and Proposition [3] 

£l ((E,£ [return v])) = ( £l (E),.) 

= = £L ((E,£[(v)H)) 

by definition of El and Proposition [3] 

This illustrates the approach used to prove simulation of most cases. Moreover, it shows the trivial 
case for E.lbl % L. 

► Case (E,£[(X,) LI ° »= e}) — -> (E,£[(X,) LI0 ]} 



E.lbl gL: 



— IHL: 



ei ((E,£[(X ; r »=«]» 

= ( £L (E), £L (£)[( £i (X / )r »=<&.(«)]> 

= ( £L (E), £i (£)[(X,r »=ft(«)]> 
^(^(E),^)^)-])) 

= ( £L (E), £i (£)[( £i (X / ))-]} 
= ( £L (E), £i (£)[ £i ((X / D]) 

= ( £l (E), £l (£[(^H)) - £L ((E,£[(X Z )H» 
by definition of El and Proposition [3] 
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— IgL: 



e L ((T.,E[(Xir »=«]» 
x £/.(£)[(.)""])) 
= (e L (Z)MEWL(m L1 °]) 

= (e L (z)MEm)n))=eL(£,Emr°})) 

by definition of and Proposition^ 



► Case 

E.lbl Q I CE.clr 
(E,£ [label I e\) — > (E,£ [return (Lb I e)])' 



— IQL: 



£ L ((2:,£ , [label/e])) 
= (e L (T.),e L (E) [label I e L {e)]) 
■L e L ((ei(Z),e L (£)[return (Lb / e L (e))})) 
= (e L (E),e L (£) [return (Lb / e L {e))]) 
= (e L (E),e L (£)[e L (return (Lb I e))]) 
= e L ((L,E [return (Lb / e)])) 



— IgL: 



e L ((E,E[label/e])) 
= (e L (E),e L (£) [label I £ L (e)\) 
■L e L ((e L (E),e L (£) [return (Lb / £ L (e))})) 
= (e L (E),e L (£) [return (Lb/.)]) 
= (£ L (E),e L (£)[e L (return (Lb I e))]) 
= £l((Z,E [return (Lb / e)])) 



► Case 

/' = E.lbl Ul Z'CE.clr E' = E[lbl \-> l'\ 



(E,£[unlabel (Lb / e)}) — > (E', E [return e]) 



Flexible Dynamic Information Flow Control in the Presence of Exceptions 



35 



- / CI: 

£ L ((E,£[unlabel (Lb / e)])) 
= (£z,(£),£z,(£[unlabel (Lb I e)])) 
= (£ L (£),£ L (£)[unlabel (Lb I E L {e))\) 
(£/.(£/.(£')), £z.(£z.(£)[return (£z.(e))])> 
= (e L (E 1 ),e L (£)[returne L (e)]) 
= (e L (E 1 ),e L (£)[e L (return e)]) 
= (£ L (E 1 ),e L (£[returne])) 
= (e L (L'),e L (E [return e])) 
= £l ((£',£ [return e])) 

where £l(E 1 ) = e L (E[lbl i-> I'}), and thus it directly follows that £l(E') = £l(£'). 

— / £L: 

e L ((E,£'[unlabel (Lb / e)])) 
= (e L (E),e L (£[unlabel (Lb / «)])) 
= (e L (E),e L (£)[unlabel (Lb / .)]) 
— > L £ L ((£ L (E 1 ),£ L (£) [return •])) 
= (£ L (£ L (E 1 )),.) 
= e L ((l!,E [return e]}) 

The last steps holds, as in the second case of return, because E'.lbl % L and any term is erased 
to •. Similarly, £l(E') = £l(E') follows as before. 

► We show an example case of the "violating rules": 
/ gE.clr 



(E,£[unlabel (Lb / e)]) — > (£,.E[throwLIOX]) 
— I CL: 



Ei^E^unlabel (Lb I e)])) 
= (£z.(E),e L (£ [unlabel (Lb / «)])) 
= (e L {L),e L {E) [unlabel (Lb I £ L (e))]> 
> L (£ L (£ L (E)),e L (e L (£)[throwLIDX])) 

(£ L (E),e L (£)[throwLIO £ L (X)]) 

(£ L (E),e L (£)[throwLIOX]) 

(£ L (E),e L (£)[e i (throwLIDX)]} 
= EL^E^throwLIOX])) 
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— IgL: 



e L ((£,£ [unlabel (Lb / e)])) 
= (£ L (E),£ L (£ [unlabel (Lb / «)])) 
= (£z.(E),£i(E) [unlabel (Lb I •)]) 
5*L (e L (e L (L)),e L (e L (E)[thTo V LWX})) 

(e L (E),e L (£)[throwLID e L (X)}) 

<£ L (E),£ L (£)[throwLIOX]) 

(e L (E) , e L (E) [e L (thr owLIO X)] ) 
= £ L ((E,£'[throwLIOX])) 

E.lbl Ql CE.clr E' = Y..<j>[a Lb / e] 

^ Cs.sc £3 fresh' 

(E^newLIORef / e]) — >■ (E',£ [return a]) 

— Z CL: 

£ L ((E,£[newLIORef / e])) 
= (e L (E),e L (£'[newLIORef I e])) 
= (e L (E),£ L (£')[newLIORef I e L (e)\ 
— > L (e L (e L (E 1 )),e L (e L (£)[returne L (a)])) 
= (e L (E 1 ), £ L (£ [return a] )> 
= £ l ({Y!,E [return a]))), 

where 6/XE 1 ) = £l(E).0[a h- Lb I e], and so £l(E 1 ) = £l(E') follows directly. 

— / ^ L: as above. However, in this case, £t(E ) = £i,(E).0[a h-» Lb / •], From Ei(T. l ).^)(a) 
e L (Lb I •) = e L (Lb I e) = e L (E').0(a) it follows that e i (E 1 ) = e L (E'). 

► Case 

/' = E.lbl Ul /'CE.clr E' = Eflbl i-> l'] 



(E,£[catch (Xi) LI ° e]) — > (L',E[eX]) 
— / CL: 



£ L ((E,£[catch(X,) LID e])) 
- (e L (E),e L ( J B[catch (X,) LI ° e L (e)])> 
= (e L (E),£ L (£)[catch(X ; ) uo e L ( e )]) 
^i. (£L(eL(E 1 )),e L (e L (£)[e L ( e )X])) 
= (e i (E 1 ),e i (£)[£ i ( e )e i (X)]) 
= (e L (E 1 ),e L (£)[e L ( e ) X}) 
= {e L {Z 1 ),e L {E)[e L {eX)}} 
= (e L (E 1 ),e L (£[ e X])) 
= (e L (E'),£L(£[eX])) 
= £ t «E',E[ e X]» 
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where e L (L l ) = £ L (E[lbl i-> /']), and directly e L (L l ) = ££.(£')■ 
— I gL: 

e L {(L,E [catch (X,)" e})) 

= (e L (E),e L (£[catch (X,) L1 ° e L (e)})) 

= (e L (I),e L (£)[catch (.) UD £ L ( e )]) 

^LfcCteP 1 ),^)^) •])) 

= £i «E',E[ e X]» 

The last steps holds since E'.lbl % L and any term is erased to •. As before, £x(E ) = £l(E') 
trivialy holds. 

□ 

Lemma 3 (Simulation) 

If The: rand (E,e) — >* (E',e') then £ L ((E,e)) — V* L £ L ((E',e')). 
Proof 

Lemma |2] shows the multi-step simulation for expressions that do not execute toLabeled. Thus, to 
show the general multi-step simulation we must first show that toLabeled preserves the simulation. 
The general simulation follows directly. 

The proof for the simulation of toLabeled follows by induction on the number of executed toLabeled. 
The base case consists of a single toLabeled. Specifically, for a computation with a single executed 
toLabeled, we have: 

(Z,e) <£'/>, 

that can be expanded into 

(E,e) — >* (£o,£[toLabeled/ e ]) — > (Eg.E [label / v]) — >* (E',e')> 

where (E ,e ) — >* (£(,, (v) LI °), and Eg = E^lbl ^ E .lbl, clr i-» E .clr]. The expansion highlights 
the first occurrence of a toLabeled, and so eo, and e' do not have any additional toLabeleds. From this 
observation it is clear that the simulation of the base case follows directly by Lemma [2] Specifically, to 
show the simulation for (toLab-1) 

E .lbl C / C Eo-clr 
(So,e ) —>•*(£(,, (v) LI °) 4-lblEZ E^=E^lbl^E Q .lbl,clr^E .clr] 
(Eo,£[toLabeled/ e ]) — > (Eg,£[label I v]) 
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where eo does not have any toLabeled we need only show the simulation of the conclusion; the simula- 
tion of the big step in the premise follows directly from Lemma|2] We show this below: 

£ L ((E ,£ , [toLabeled/ (e ) LI0 ]>) 
= (£ L (£o),£ L (£[toLabeled/ (e ) L1D ])> 
= (e L (Eo),e L (£)[toLabeled/ (£z(e )H) 
— > L (e L (e L (Z n )),e L (e L (E)[la.belle L (v)})) 
= (£ L (£2),£ L (£)[label/e L (v)]) 
= {e L (E2),e L ( J B[label/v])} 
= ei((£g,£[label / v]» 

Correspondingly, the simulation of the (EQ,£'[label / v]) — >* (£',e') step follows directly by Lemma|2] 
The simulations of (toLab-2) follows similarly. 

It is worth noting that the simulation of (BIND-1), as proved in LemmaQ] holds for exception labels, 
irrespective of the current label. This is a necessary condition when a computation executes toLabeled 
as the current label and exception label may not always be the same. 

Our inductive hypothesis states that the simulation of 

<£,,) ->* <EV>, 

holds for the case where toLabeled is executed k times. With this assumption, the simulation of 

(Z,e) <£'/}, 

with k + 1 toLabeled executions, follows in a similar manner to the base case. Specifically, searching for 
the first toLabeled and expanding, we have: 

first big-step second big-step 

/ * A v 

(£,e) — >* (Eo,£[toLabeled/eo]> — >* (^V) 

where at most k toLabeleds could have been executed in the first big-step, the inner computation eo, or 
the second big-step. The simulation of all these execution steps follows by application of the inductive 
hypothesis. □ 

Theorem 1 (Non-interference) 

Given a computation e (with no •, ( ) LI °, Lb, or Xi) where The: Labeled It — > LIO £ (Labeled I t'), 
environments £1 and £2 where T.\.<p = T.2-(j) ~%, security label I, an attacker at level L such that / C L, 
then 

Veie2-(r h e t : Labeled £ t),=i.2 A (e t = Lb / e0i=i,2 A (Ei,ei) (£2,^2) 
A (Z h e ei ) — ►* (Z[,(viD A (Zi,e e 2 ) — >* (£ 2) (v 2 ) LI °) 
=> (£' 1 ,(v 1 D« i (£2,(v 2 r) 

Proof 

From Lemma|3] for i = 1 , 2, we have 

£i ((£ ne (Lb/ e ;)))^ £L ((£;,(v ; -n), 

where v,- = Lb Z, e'f or v, = X[«. First we highlight that: 

e L ((I.,e))=e L ((lf,e'}) =► (£, e ) » £ (If,e') 
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Note that the converse is not necessarily true, since the stores may differ in the references with labels 
above L. Then, from the determinacy of — >i, given in Proposition [2] and since the starting environment 
configurations are the same (observe that (Ei ,e (Lb I e\)) «l (^2,6 ' e i)) £ l((^i ,e (Lb I e\))) = 
£L((E 2 ,e (Lb I e' 2 ))) since Ei.0 = E 2 .0 = 0), it must be that the end environment configurations also be 
the same, i.e., ei,((Z / 1 , (vi) LI °)) = £/,((E 2 , ( V 2) LI °))- The L-equivalence directly follows from the above 
observation. 

For completeness, we detail the following cases: 

► Case E,-.lbl % L: We have 

e L m,e (Lb Z *{)» = (ftfr),.) — £ <<&.$),•> = e L m, (viD)- 

From the determinacy of — >i, it must be that the end environment configurations are the same, 
from which it directly follows that (E'j, (vi) LI °) ms L (E 2 , (v 2 ) LI0 ). 

► Case E,-.lbl CLAEj.lbl %L: We have 

e L ((E„ e (Lb I $)) = <ft(E,),ft(e) (Lb I ft («',))) — £ = ft«4 (v/D). 

As before, since the initial environment configurations are the same, from the determinacy of — >i 
we end with the same configuration, which directly corresponds to L-equivalence. 

► Case E/.lbl CLAEj.lbl CL: We have 

ft((E,-, e (Lb / e\))) = (e£,(Ej),ej,(e) (Lb I e L {e[))) -+* L (£l(EJ), (v/) lid ). 
From the determinacy of — >i, it must be that £l(Ej) = £l(E 2 ) and ft(vi) = £l(i'2), and directly 

{^,(vir>« £ (E 2 ,(v 2 r>. 
□ 

Theorem 2 {Store confinement) 

Given labels Z and l c , a computation e (with no •, a, ( ) LI °, Lb, or X)i) such that The: LIO I T, and 
environment E[lbl i— > I, clr n> Z c ] where Z C Z c , then 

(E, e ) — >* (E',(v)-) => (E.</>) ; , = (E'.0) y A(E.0) t/c = (E'» t/t . 

Proo/ 

By contradiction. We show the case of creating new referneces, the case of modifying an existing reference 
follows similarly. Suppose that 

► (E.^jj ^ (E'.</>) ;/ . Then, 3(a,Lb l v e a ) £ (E'.0 );,.(«, Lb l v e a ) <£ (E.0) ;/ and I % l v . Moreover, 
(by Proposition HI there must be a step at which point the new reference is created: (E',e) — >* 
(E„,L[newLIORef l v e a \) — >* (E', (v) LID ), such that (E.0);/ = (E a .0);/. However, by (nRef) it 
must be that I C Z v . Hence, we have a contradiction. 

► (E.0) t4 . ^ (E'.0) tfe . Then, 3(a,Lb Z v e a ) G (E'.0) tfe .(a,Lb Z v e„) £ (E.0) tfe and Z v £ Z e . Moreover, 
(by Proposition [5]) there must be a step at which point the new reference is created: (E',e) — >* 
(E„,L[newLIORef Z v e„]} — >* (E' ; (v) L1D ), such that (E.0) t , c = (E a .^) tfe . However, by (nRef) it 
must be that Z v C Z c . Hence, we have a contradiction. 

□ 
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Given labels /, l c , and l v , a computation e (with no •, a, ( ) LID , Lb, orX//) where The: LIO I (Labeled i t), 
and environment E[lbl M> /, clr n- l c ] such that / C Z c , then 

(E,e) — >* (E',(Lb/ v ei) LI °) / C / v C i c V3(a,Lb/] e' x ) eE.0.Lb/ v ej e e'j A/i E 

Here, operator e is defined as the syntactic appearance of the left-hand expression into the right-hand side 
operand. 

Proof 

Since e cannot contain Lbs, the final labeled value must be created or retrieved from the store. By induction 
on expressions and evaluation contexts and using Propositions|4]and[5]it must be that the label of the value 
is bounded by the initial current label and clearance or the labeled value appears syntactically in the store. 
The proof follows by case analysis on how a Labeled value can be obtained. 

Suppose the value is created, i.e., fl(a,Lb li e\) 6 E.^.Lb l v e\ e e\ Ah E h Then, there must be an 
intermediate step where the labeled value is created. Specifically, (E,e) — >* (Ei,£[label /,, ei]) — >* 
(E', (Lb l v ei) LI °). (Recall that toLabeled also reduces to label, thus we need only handle this case.) 
Hence, from rule (Lab) it must be that Ei .lbl C C Ei .clr and by Propositions!?] and |5] it must be that 
IQlvQ lc 

Suppose that the value is not created with label. Then, 3(a,Lb l\ e'j) 6 E.0.Lb l v e\ e e\ and l\ □ l c . 
The l\ C l c must hold since there must be an intermediate step where the reference is read. Specifically, 
(E,e) — >* (Ei^readLIORef a]) — > (E'j ,E [return e\]) — >* (E',(Lb l v ei) LI °). From rule (rRef) it 
must be that l\ C Ei.clr and by Proposition [5] it directly follows that l\ C l c . Because our semantics 
does not have the evaluation context £::=••• Lb e E, the values of references are not always evaluated 
and thus the labeled value Lb e\ must syntactically appear in e\. For example, if e\ = 2, it holds that 
e\ e Ax. if x then (Lb l v 2) else (Lb l w 3), but not e\ e /Lx.if x then (Lb (1 + 1)) else (Lb l w 3) for 
some l w . □ 



